docs(accuracysnes): adjudicate ares' divergences; two corrections to my own claims - #305

Follow-up to #304, which established the ares host and reported five divergences without adjudicating them.

Three of the five are rows snes9x already fails

The tally alone does not show this, and it changes what each row means:

So ares is corroborating snes9x on three rows rather than standing alone. Still not wired into crossval.sh: an ARES_KNOWN_FAILURES constant encoding unadjudicated disagreements would be worse than no third reference.

Correction 1 — to my own README and to PR #304

I wrote that F1.10 is a PAD2_CONTRACT row and that this host'''s port detection should be suspected first. That is wrong. f1_require_contract reads $4016 only — port 1 — and F1.10 code 2 means "$4212 read busy at the very start of the vblank line", which does not involve controller state at all. I inherited the claim from crossval.sh'''s Mesen2 grouping instead of checking it.

Correction 2 — to crossval.sh

Its MESEN2_KNOWN_FAILURES comment names idx279 F1.03 and idx286 F1.10. In the current catalogue those indices are F1.01 and F1.08 — an index moves whenever a test is added ahead of it. Now keyed on row names, with the drift stated: an index in a comment is a fact with a shelf life.

That same comment attributes Mesen2'''s F1.10 failure to the port-2 limitation, while the snes9x block a few lines above says Mesen2 passes F1.10. Both cannot be true. Marked as doubted rather than quietly rewritten — resolving it needs Mesen2'''s failing set read at DONE and mapped through SOURCE_CATALOG.tsv, a measurement nobody has taken since the catalogue grew.

And F1.10 now deserves a hard look

fullsnes puts the automatic read'''s start ~dot 32.5–95.5 into the first vblank line rather than at the vblank edge. snes9x fails that row; ares fails it; and if the Mesen2 attribution is right, Mesen2 fails it too — leaving RustySNES passing alone, on a row it passes only because of a deliberate fix. This project'''s heuristic says RustySNES failing alone means a real bug. It should say the same about RustySNES passing alone.

Verification

REF_PROJ=$PWD/ref-proj bash scripts/accuracysnes/crossval.sh — unchanged: snes9x: OK (14 known), Mesen2: OK (2 known), 54 scenes match on both, 2 reference(s) agree with the cart. bash -n clean. Docs and comments only.

🤖 Generated with Claude Code

Summary

This change updates AccuracySNES dossier assertions from ares comparison results.

• The dossier now claims that three of five ares failures also fail in snes9x. E8.02 and E3.06 remain ares-only. This claim is false if fresh comparison results change either the overlap or the ares-only rows.
• The dossier now claims that F1.10 reads $4016, while code 2 concerns $4212 busy status at vblank start. The previous PAD2_CONTRACT attribution is false.
• Mesen2 references now use stable row names. The F1.10 attribution remains unresolved because recorded behavior conflicts. The claim is false if fresh measurement confirms one attribution.
• The dossier flags F1.10 for investigation because RustySNES may pass the row alone despite the deliberate fix. This claim is false if isolated testing shows RustySNES fails or the fix is not causal.
• Coverage remains 54 matching scenes. The coverage denominator did not move.
• Verification remains unchanged: both reference hosts pass, and shell syntax checks pass.